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topology information manager keeps fragments of network 
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SECURE DISTRIBUTION AND USE OF 
WEIGHTED NETWORK TOPOLOGY 
INFORMATION 

HELD OF THE INVENTION 

5 

The present invention relates to path selection in com- 
puter networks, and relates more particularly to providing 
secure but efl5cient access to information about costs asso- 
ciated with different paths in a network. 

TECHNICAL BACKGROUND OF THE 30 
INVENTION 

Cbmputer networks are very flexible. A network can be 
viewed as a conduit for messages, in that data enters the 
network at one or more points, is transmitted through the 
network, and leaves the network at one or more other points. 
A network can also be viewed as a repository of data and/or 
as a source of data. A network is a repository if data enters 
the network at one or more points and travels to a storage 
location in the network. A network is a source of data if 

20 

previously stored data or internally generated data travels 
out of the network or is sent to a different location in the 
network. 

The flexibility of a given network arises in part from the 
internal organization of the network as a coUection of linked ^5 
nodes. When data is sent from one user to another, or 
between a user and a repository, the data travels in turn from 
node to node to node until it reaches its destination. Because 
data can often leave a given node over any of several links, 
a large number of routes may exist between any two nodes 
which are not immediate neighbors of one another. Often, 
however, some routes are better than others. The process of 
choosing a route in a particular situation is called "routing" 
or "route selection." Routes are sometimes called "paths." 

Because route selection is both important and 35 
challenging, it has been the object of much study and 
experimentation. One set of challenges involves selecting 
appropriate ways to measure the costs associated with 
different network links and nodes. For instance, a weight 
may be associated with each link and each node in a network 
based on the item's measured or expected performance; the 
weight may reflect characteristics such as bandwidth, 
latency, reliability, memory size, and/or processor speed. 

A second set of challenges involves mapping connectivity 
by identifying which links and nodes arc connected. Various 45 
exploration protocols have been devised and applied to map 
the connections in networks. One main goal of such proto- 
cols is performing the mapping with the smallest necessary 
amount of network bandwidth and other resources. Another 
goal is providing sufficiently rapid updates when a node or 50 
link does down, is removed, is added, or returns to service. 

Another set of challenges involves using topology infor- 
mation (information about weights and/or connectivity) to 
identify the desirable paths in a given network at a given 
time. Various methods can be used to identify the "best" 55 
route between two nodes, namely, the route having the 
lowest total weight. If the computing resources needed to 
identify the best route are too expensive, then "near- 
optimal" or "pretty good" routes may be identified instead. 

Further challenges are posed by the question of when and 60 
how to update topology information. Updates may include 
changes to current routing information and/or the addition of 
wholly new routing information. Routing protocols such as 
the RIP (Routing Information Protocol) and OSPF (Open 
Shortest Path First) protocols allow routers to request and 65 
obtain information from neighboring routers about paths to 
other routers. 



Instead of trying to compute the entire route from scratch 
each time, some systems store partial computational results 
and reuse them when possible. For instance, U.S. Pat. No. 
5,321,815 issued to Bartolanzo, Jr. et al. describes a process 
for selecting a least weight path between two nodes in a 
network using partial trees which were created and cached 
in prior route selection operations. 

Some systems also distribute the task of selecting a route. 
For instance. U.S. Pat. No, 5,398,012 issued to Derby et al. 
describes a distributed process for determining the best 
communication route from a source end station to a desti- 
nation end station. Network nodes, at the interface between 
a wide area network ("WAN") and each subnetwork , 
contain access agents to control the communication flow 
between the wide area network and an end station in the 
subnetwork . ThG task of selecting the best route between two 
end stations is distributed between the access agents at the 
WAN interface in the first subnetwork and the access agents 
at the WAN interface in the second subnetwork. 

However, previous work has not adequately addressed the 
problem of providing secured access to the network topol- 
ogy. In general, the route selection agents and processes in 
a given network have been given ready access to detailed 
information about the network's nodes and about the links 
between the nodes. In some networks, this poses a security 
risk, because such knowledge could be used to intercept or 
eavesdrop on communications, to masquerade as an autho- 
rized user, and/or to insert spurious data packets into the 
network. 

Accordingly, it would be an advance to provide an 
approach to routing which takes advantage of existing tools 
but also enhances the security of network topology 
information, and which does so in an efficient manner. 

Such an approach to secure network topology storage and 
use is described and claimed below. 

BRIEF SUMMARY OF THE INVENTION 

The present invention provides methods, systems, signals, 
and devices for secure access to a digital representation of a 
network topology and secure use of topology information, 
ITie digital representation of the topology may include a 
database, tables, linked lists, graphs, and/or other data 
structures representing the nodes and links and their capa- 
bihties. For convenience, the digital representation and the 
topology it represents are both referred to here as the 
topology. Suitable topologies include both conventional 
topologies and proprietary topologies now known and here- 
after invented. 

Pieces of topology information such as partial trees and 
hidden paths are stored at one or more locations throughout 
the network, on disk or other permanent media. The topol- 
ogy information may also be stored locally in a fast but 
volatile cache. Any given node does not necessarily have a 
complete description of the entire network topology, and the 
union of all information fragments is not necessarily com- 
plete. Moreover, since the network topology changes when 
a node or link goes down or is added, and since the topology 
may also change in response to varying loads on the network 
linksj the fragments of topology information are not neces- 
sarily current. In general, however, the fragments are useful 
in selecting routes for data transmission within or across the 
network. 

In some embodiments of the invention, the topology 
information on a given node is managed by a Topology 
Information Manager ("TIM"). The 'IIM may be imple- 
mented as an agent or other process which provides infor- 
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matioQ both from and about the topology fragments it network topology fragments which are located in a distrib- 
manages. Some of the fragments may be freely available, uted computing environment. Suitable distributed environ- 
but the TIM provides access to other topology fragments ments include local area networks, wide area networks, the 
only in response to authenticated requests. Conventional or Internet, and/or other computer networks, 
proprietary authentication methods may be used to authen- 5 For convenience, definitions of several terms are provided 
ticate the requests. Thus, detailed information about some or below. These definitions are further refined by discussions 
all of the network's nodes and links is available only to and examples located throughout this document. "Internet" 
authenticated users. includes variations such as a private Internet, a secure 
Topology Information Managers may be identified by a Internet, a value-added network, a virtual private network, 
network -wide naming convention, or they maybe located on ^0 an extranet, or an intranet. 

specific nodes such as gatekeeper nodes, or they may be a "network" may include one or more LANs, wide-area 

identified in a directory. If present, the directory may be a networks, Internet servers and clients, intranet servers and 

monolithic directory, or it may be a distributed directory clients, peer-to-peer nodes, network operating servers and 

such as a Novell Directory Services ("NDS") distributed clients, or a combination thereof. 

duectory. ^ ^ "computer" may be a workstation, laptop computer. 

In some embodiments a Path Selector gathers information disconnectable mobile computer, server, mainframe, 

about the network topology, using at least one TIM, and then so-caUed "network computer" or "thin client", personal 

selects a path. Like TIMs, Path Selectors may be monolithic digital assistant or other hand-held computing device, 

or distributed. A given Path Selector may gather topology "smart" consumer electronics device or appliance, or a 

information from a combination of TIMs and other sources, combination thereof. 

or the iDformatioD may be gathered using no «>urce except ^ ,. ^^^^^^^ '^^^ ^^^^ individual passwords, pass 

TIMs. Using the gathered mformation. the Path Selector ^^ biometric scan results (e.g. retinal scan, 

chooses a path which may be an optimal path, a near^ptunal g Hnt). asymmetric keys, symmetric keys, or other 

path, or some other type of path In some embodiments cryplo-graphic or digital signature keys, email or other 

nMs accept packets and transmit them between specified id,„,if j ^^^.^ ^ib^r data or device used to protect 

nodes wilhou revealing the exact path(s) used, thereby „^ ^^^^ j„ ^„ ^^^j^^^ resource in the 

allowing a Path Selector which does not have the right to distributed svstem 

view all of a topology fragment to nonetheless use summary „ / , . . 

information about a hidden path when selecting a path. . ^° administrator, or it may refer to a 

; \ ,30 non-administrative regular user. In either case, a user may 

In short, the present invention provides tools and tech- ^ ^ ^j,^^^^ 

niques for securely and efficiently managmg and using ^„ „ legitimately on behalf of a person 

network topology information whicb can be distributed in a „ «f 

11,,.. , , 1 . or a group or people, 

computer network. In addition to those described above, Djs^buted Computing Systems 

other features and advantages of the mvention will become 35 ^ ^ion of one of the distributed computing systems 100 

more fuUy apparent through the following descripUon. ^^^^ ^^^^^^ ^^^^^.^^ ^ ^^^^ P,q ^ 

BRIEF DESCRIPTION OF THE DRAWINGS embodiment, the system 100 includes Novell Net- 

Ware(g) network operating system software (NETWARE is a 
To illustrate the manner in which the advantages and registered trade-mark of Novell, Inc.) and Novell Directory 
features of the invention are obtained, a more particular 40 Services ("NDS") software. In alternative embodiments, the 
description of the invention will be given with reference to system 100 lacks NetWare and/or NDS software and 
the attached drawings. These drawings only illustrate includes NetWare Connect Services, VINES, RADIUS, 
selected aspects of the invention and thus do not limit the TCP/IP, IPX, NetBEUI, NetBIOS, Windows NT, Windows 
invention's scope. In the drawings: 93, Windows 95, LAN Manager, and/or LANtastic network 
FIG. 1 is a diagram illustrating one of the many distrib- 45 operating system software and/or an implementation of a 
uted computing systems suitable for use according to the distributed hierarchical partitioned object data-base accord- 
present invention. ing to the X.500 protocol or another directory service 
FIG. 2 is a data flow diagram further illustrating an protocol such as the Lightweight Directory Access Protocol 
embodiment of the invention in the system shown in FIG. 1. (VINES is a trademark of Banyan Systems; WINDOWS NT, 
HG. 3 is a diagram illustrating a Path Selector according ^0 WINDOWS 95, WINDOWS 98, and LAN MANAGER are 
to the present invention trademarks of Microsoft Corporation; LANTASTIC is a 
RG. 4 is a diagram illustrating a Topology Information trademark of Artisoft). Tlie illustrated system IttO includes 



Manager according to the present invention. 



two local area networks 102 which are connectable to other 

* - 1, M, . , . ^ . networks 104, including other LANs or portions of the 

HG. 5 IS a flowchart Illustrating topology mfonnation internet or an intranet, through a gateway or similar mecha- 

management and use methods of the present invention. ^^^^^ embodiments include a single network 102. 

no. 6 LS a diagram illustrating a template for request As shown, each network 102 includes one or more servers 

signals to a Topology Information Manager accordmg to the io6 that are connected by network signal lines 108 to one or 

present invention. more network clients 110. The servers 106 and network 

FIG. 7 is a diagram illustrating a template for Topology 60 clients 110 may be configured by those of skill in the art in 

Information Manager signal responses to a request such as a wide variety of ways to operate according to the present 

that shown in FIG. 6. invention. The servers 106 may be configured as Internet 

DETAILED DESCRIPTION OF THE f ^T'^ ^''^ 'I ^'"""^ 

PREFERRED EMBODIMENTS „ directory service providers, as name 

65 servers, as software component or servlet servers, as data- 
ble present invention relates to methods, devices, signals, base servers, or as a combination thereof. ITie servers 106 
and systems for securely and efficiently managing and using may be uniprocessor, multiprocessor, or clustered processor 
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machines. The servers 106 and clients 110 each include an 
addressable storage medium such as random access memory 
and/or a non-volatile storage medium such as a magnetic or 
optical disk, ROM, or flash memory. 

Suitable network clients 110 include personal computers 5 
112; laptops, pagers, cell phones, personal digital assistants, 
and other mobile devices 114; workstations 116; and dumb 
terminals. One or more of the servers 106 and/or one or more 
of the clients 110 may act as routers in a conventional 
manner and/or in a manner taught by the present invention. 
The signal lines 108 may include twisted pair, coaxial, or 
optical fiber cables, telephone lines, satellites, microwave 
relays, modulated AC power lines, RF connections, and/or 
other data transmission "wires" known to those of skill in the 
art. In addition to the network client computers 110, devices 
such as printers 118 or disk arrays 120 may also be attached 
to the network 102. A given computer may function both as 
a client 110 and as a server 106; this may occur, for instance, 
on computers running Microsoft Windows software. 
Although particular individual and network computer sys- 
tems and components are shown, those of skill in the art will 20 
appreciate that the present invention also works with a 
variety of other networks, computers, and devices. 

The servers 106 and many of the network clients 110 are 
often capable of using floppy drives, tape drives, optical 
drives or other means to read a storage medium 122. A 25 
suitable storage medium 122 includes a magnetic, optical, or 
other computer- readable storage device having a specific 
physical configuration. Suitable storage devices include 
floppy disks, hard disks, tape, CD-ROMs, PROMs, random 
access memory, ROM, flash memory, and other computer 30 
system storage devices. 

The physical configuration represents data and instruc- 
tions which cause at least part of the computer system 100 
to operate in a specific and predefined manner as described 
herein. Thus, the medium 122 tangibly embodies a program, 35 
functions, and/or instructions that are executable by the 
servers 106 and/or network client computers 110 to perform 
topology fragment management and use substantially as 
described herein. 

Suitable software and/or hardware implementations 40 
according to the invention are readily provided by those of 
skill in the art using the teachings presented here and 
programming languages and tools such as Java, Pascal, C++, 
C, Perl, shell scripts, assembly, firmware, microcode, logic 
arrays, PALs, ASICs, PROMS, and/or other languages, 45 
circuits, or tools. 
Data Flow Overview 

FIG. 2 illustrates in a data flow diagram the components 
of one embodiment of the invention and related parts of a 
distributed system such as the system 100. In discussing 50 
FIG. 2, reference will also be made to FIG. 1. 

A message 200 is to be sent from a source 202 to a 
destination 204 in a distributed computing system such as 
the network 100. In one embodiment, the source 202 sends 
the message to a path selector 206, which selects a path 55 
toward the destination 204 and sends the message 200 on its 
way. The path selected may take the message 200 all the way 
to the destination 204, or it may take the message 200 only 
part of the way, in which case the message 200 may be 
routed by other path selectors 206 or other routing tools 60 
before reaching the destination 204. In an alternative 
embodiment, the source 202 identifies the destination 204 to 
the path selector 206, which selects a path and informs the 
source 202; the source 202 then sends the message 200 on 
its way. 65 

'Ilie path selector 206 includes several components, as 
discussed in greater detail below in connection with FIG. 3. 
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In particular, the path selector 206 includes an authentication 
component 208 for authenticating exchanges as discussed 
herein. The authentication component 208 may be imple- 
mented as a separate package or module, such as a NetWare 
Loadable Module. It may also take some other familiar form 
such as integrated code, or it may be a collection of one or 
more components or objects implemented using Java or 
.DLL or COM or OLE tools and techniques. 

Authentication of the path selector 206 may be accom- 
plished using a key (as defined above) with means and 
methods familiar to those of skill in the art. Based on its 
identity in the system 100, the path selector 206 has rights 
which are enforced by an access control system. Suitable 
rights may be defined in databases or in administrative files 
defining user accounts and user groups. A rights database 
may be integrated with a directory service, such as a 
Lightweight Directory Access Protocol service, a Novell 
NDS directory service (NDS is a mark of Novell, Inc.), or 
other X.500 directory service. Suitable access control sys- 
tems may draw on conventional means and methods such as 
those employed by the Novell NetWare operating system, 
the Open System Foundation Distributed Computing Envi- 
ronment approach, and operating systems such as the UNIX, 
MULTICS, and Windows NT systems. Suitable access con- 
trol systems may employ access control lists, capabilities, 
groups, permissions, tokens, credentials, and other authen- 
tication information. 

The path selector 206 authentication component 208 
sends authentication information 210 to a topology infor- 
mation manager 212. The authentication information may 
include information identifying the path selector 206, but in 
any case includes credentials, tokens, or other information 
that can be used to authenticate the request. The topology 
information manager 212 includes several components, as 
discussed in greater detail below in connection with FIG. 4. 
In particular, the topology information manager 212 
includes an authentication component 208 for authenticating 
exchanges with the path selector 206 as discussed herein, 
^rhe topology information manager 212 authentication com- 
ponent 208 may be functionally identical with the path 
selector 206 authentication component 208, as illustrated in 
FIG. 2. Alternatively, the topology information manager 212 
and the path selector 206 may employ different but interop- 
erable authentication components. 

If the attempt of the path selector 206 to authenticate itself 
to the topology information manager 212 fails, then one or 
more of the following steps may be taken, depending on the 
embodiment involved: the manager 212 may grant the path 
selector 206 access to topology information 214 which is 
openly available to any user while refusing access to other 
information 214; the manager 212 may grant the path 
selector 206 limited access to topology information 214 on 
the basis of an earlier authenticated request; or the manager 
212 may notify the system administrator and/or make a log 
entry summarizing the failed authentication attempt. Other 
options are described in connection with FIG. 5. 

The topology information manager 212 controls access to 
one or more topology information fragments 214. A given 
topology information manager 212 may have a complete, 
current copy of the network topology, but does not neces- 
sarily have such a copy. Fragments 214 covering only a 
portion of the network and/or fragments 214 which are not 
entirely current may also be advantageously managed 
according to the invention. 

In FIG. 2, these fragments 214 are resident in the manager 
212, but they may also be kept elsewhere, such as at a hidden 
location and/or in an encrypted form. A copy of some or all 
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fragments 214 may also be cached in RAM for faster access. 
The fragments 214 may be rebuilt and/or updated in 
response to an access request, or previously built fragments 
214 may be provided on an "as is" basis. Familiar routing 
protocols, supplemented by authentication according to the 5 
invention, may be used by managers 212 to update their own 
routing tables and/or other sources of topology information. 

Each fragment 214 includes information about the topol- 
ogy of the network 100 and/or other networks 104. The 
topology information 214 may include representations lo 
familiar in the art, with weights assigned by conventional or 
proprietary tools and techniques. Multiple weights may be 
assigned to a given link. For instance, the weight may be 
assigned on the basis of the speed of node's processor, the 
amount of memory available to a node's processor, the 15 
bandwidth of the "wire(s)" in a link, or some combination of 
these and other performance characteristics. The topology 
information 214 may be kept in the form of partial trees, 
weight graphs, or other linked structures. Topology infor- 
mation 214 may also be kept in the form of hidden paths, 20 
which include endpoints for a subnet without revealing all 
information about the topology between the endpoints. 

If the request by the path selector 206 for topology 
information 214 is authenticated, then the manager 212 
sends one or more topology information fragments 214 to 25 
the path selector 2(NS. The path selector 206 uses the 
topology information 214, possibly in conjunction with 
topology information gained from other managers 212 and/ 
or other sources, by selecting a path for the message 200. 

In some cases, the path selector 206 then sends the 30 
message 200 on its way; in other cases, the message 200 is 
given by the path selector 206 to the manager 212, which 
forwards the message 2(M) along a hidden path. If the 
message 200 is forwarded by the manager, the hidden path 
normally includes one or more links or nodes 220 that were 35 
not revealed by the manager 212 to the path selector 206. 
The path selector 206 may also select a path which lies in 
part or in whole along links and nodes 222 that were not 
among those whose information 214 is managed by the 
manager 212. In some cases a combination of visible 218, 40 
hidden 220, and/or non -managed 222 nodes and links is used 
as the message 200 travels toward the destination 204. 

Hidden paths may be nested or used in series. For 
instance, a given message 200 may be forwarded by a first 
manager 212 along several nodes and links that are hidden 45 
by the first manager 212 from a path selector 206, after 
which the message 200 is given by the first manager 212 to 
a second manager 212 for forwarding along a second hidden 
path. The second manager 212 may hide nodes and links in 
the second path from both the first manager 212 and the path 50 
selector 206, or it may hide them from the path selector 206 
only. At the end of the second hidden path, the message 200 
may travel along nodes and links which are known lo the 
first manager 212 but hidden from the path selector 206, or 
the message 200 may travel along nodes and links that are 55 
known to the path selector 206. The two hidden paths may 
be used because the two managers 212 have different 
security levels, because they require different keys, and/or 
because they contain fragments 214 describing different 
parts of the network. 60 
Path Selector 

With continued reference to the earlier Figures, FIG. 3 
further illustrates one embodiment of the path selector 206. 
A path selection component 300 evaluates network topology 
information and selects one or more paths over which the 65 
message 200 will be sent toward the destination 204. llie 
path selection component 300 may use familiar or propri- 
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etary tools and techniques to select paths, and may make its 
selections according to various criteria. For instance, the 
path selection component 300 may traverse a weighted 
partial tree to identify a best path or a near-optimal path. 

A topology information request component 302 makes 
requests for network topology information and provides the 
information it obtains to the path selection component 300 
for possible use in the path selection process. The requests 
may be made at the behest of the path selection component 
300, or they may be made proactively by the request 
component 302. The requests are provided with credentials, 
keys, and/or other authentication information by the authen- 
tication module 208. The requests may seek all available 
information from particular sources, such as the nearest 
manager 212, or they may seek all available information 
from all sources regarding a specified node or set of nodes, 
such as the source node 202 and/or the destination node 204. 
Requests are discussed further in connection with FIG. 6. 

In some embodiments, one or more managers 212, and 
possibly other sources of topology information as well, are 
identified in a directory. The directory, which is accessed by 
the path selector 206 through a directory interface 304, may 
be implemented in various ways. The directory may be 
monolithic or distributed. It may include little more than a 
list of network addresses kept in a file of a specified name 
and maintained by hand. Or it may be a distributed directory 
which uses replicated partitions, such as a directory accessed 
through Novell Directory Services. 
Topology Information Managers 

With continued reference to the earlier Figures, FIG. 4 
further illustrates one embodiment of the topology informa- 
tion manager 212. Requests for topology information 214 
are authenticated by the authentication component 208; if 
authentication of a given request fails, that request is denied 
and/or brought to the attention of an administrator. 

A response component 400 responds to authenticated 
requests for topology information 214 from path selector(s) 
206 and possibly from other requesters as well. For instance, 
network resource inventory and management tools may 
utilize the manager 212 even if no router or path selector 
does. Responses are also discussed in connection with FIG. 
7. 

The responses provided vary according to the simation. If 
the request seeks information 214 which is access- restricted, 
and the authentication component(s) 208 do not authenticate 
the request, then the response may be as simple as "access 
denied", or it may direct the requester to other sources or to 
administrative personnel. On the other hand, some requests 
might always succeed. For instance, topology information 
214 which is not access restricted may be managed by the 
manager 212 during initial system setup, or during system 
maintenance, or even during normal system operation for 
ease of administration. If the request seeks such unrestricted 
topology information 214, or the request is authenticated 
and seeks allowable access-restricted information, then the 
response component 400 provides the information 214 to the 
requester. 

As discussed, the topology information 214 may include 
hidden paths, partial trees or graphs which have been 
previously built and then cached or otherwise stored, partial 
trees of graphs which are built in response to the request, or 
complete topologies for one or more networks. If hidden 
paths 220 are involved, a forwarding component 402 may be 
used to forward messages 200 along such paths. This 
capability allows the path selector 206 to take into consid- 
eration at least some of the network topology of the hidden 
paths before committing the message 200 to a path, without 
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compromising the security of networks or network portions 
that are summarized by the hidden path information, and to 
use the hidden path if it is the most desirable path. 

A storage component 404 stores the topology information 
214 in a cache 406 and/or on disks 408 or other non-volatile 5 
media. The storage component 404 may interface with a 
distributed replicated partition database which contains 
topology information 214, or the information 214 may 
simply be kept on a local disk at each manager 212. Updates 
to topology information 214 may be kept locally only, or lo 
they may be propagated to other managers 212. Illustrative 
updates include information 214 which reflects the addition 
of one or more new nodes and/or links, the determination 
that one or more nodes and/or links are down, and weight 
changes corresponding to updated data about the perfor- is 
mance of nodes and/or links. 
Methods 

FIG. 5 illustrates methods of the present invention. Dur- 
ing an informing step 500,/ topology information 214 is 
placed on one or more nolles so that managers 212 can 20 
access it and use it in responding to requests from path 
selectors 206 and other requesters. As an alternative, or in 
addition to distributing previously generated topology infor- 
mation 214, the managers 212 may generate the information 
214 by sending inquiry packets, measuring response times, 25 
and other famihar means. 

As jndicatecl by Fid. 5, the informing step 500 may also 
be delayed, so it is performed in order to respond to a 
particular authenticated request. More generally, even 
though FIG. 5 shows steps being performed in particular 30 
orders they may also be performed in other orders or 
concurrently, except when one step requires the result of 
another step. 

During a request making step 502, a path selector 206 or 
other requester makes a request for topology information 35 
214. Suitable request formats are discussed in connection 
with FIG. 6. During a receiving step 504, the request is 
received by the manager 212. Suitable means for transmit- 
ting the request to the manager 212 are well known in the art, 
including network communication tools and techniques as 40 
well as interprocess communication tools and techniques 
such as remote procedure calls and shared memory. In many 
cases the requesting step 502 and the receiving step 504 will 
be performed on different network nodes, but the requester 
and the manager 212 may also run on the same node in some 45 
embodiments. 

During an authenticating step 506, the manager 212 
authenticates the request. As discussed above, administra- 
tive tracking steps such as logging the attempt or emailing 
an administrator can be taken if the attempted authentication 50 
fails. If the authentication succeeds, then a copy of the 
available topology information 214 to which the requester is 
entitled is sent to the requester; alternatively, a read-only 
original of the information 214 is made available to the 
requester. The topology information 214 and/or other 55 
response is sent to the requester during a responding step 
508. Responses are discussed further in connection with 
FIG. 7. 

During a path selecting step 510, a requesting path 
selector 206 uses the topology information 214 to select one 60 
or more paths. The selected path may include a hidden path 
220, in which case another requesting step 502 requests that 
the message 200 be forwarded by the manager 212 along the 
hidden path 220 during a forwarding step 512. For instance, 
one of many possible sequences of steps in the embodiment 65 
shown is to request 502 topology information, receive 504 
the request, authenticate 506 the request and/or the 
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requester, respond 508 by providing topology information 
about a hidden path, select 510 a path which includes the 
hidden path, request 502 that the message be forwarded 
along the hidden path, receive 504 the forwarding request, 
authenticate 506 the forwarding request, and then forward 
512 the message. Path selection and forwarding are also 
discussed in connection with FIG. 2 and elsewhere. 
Topology Information Request 

One suitable signal format for making requests to one or 
more managers 212 is shown in FIG. 6. A request 600 
includes-^a requester identification component 602 which 
identifies the user that is making the request. The requesting 
user may be a path selector 206, a topology information 
manager 212, or some other user. Identification Ls provided 
by a user ID, process ID, GUID, UUID, account number, 
name, public key, private key, synimetnc key, token, or other 
identificatiorTmeans; many suitable identification means are 
familiar in the art. 

An authentication component of the request 600, such as 
the requester's credentials 604, may be present. 
Alternatively, the requester identification 602 may serve 
both to identify the user and to authenticate the request 600. 
The authentication component includes sufficient 
information, such as an account password, data from a 
magnetic card, data from a biometric scan, and/or certificate 
or other credential, to determine whether the requesting user 
is entitled to the topology information 214 it seeks. In the 
case of requests 600 which include routing table 214 updates 
from the requesting user, the authentication component 
includes sufficient information to determine whether the 
requesting user is a trusted source of updates to managed 
fragments 214. 

Suitable certificates include, without limitation, certifi- 
cates issued by a Certification Authority. A Certification 
Authority may be a dedicated and/or centralized certification 
authority of the type found in a public key infrastructure, or 
it may be an alternative certification authority such as a 
member of a PGP (Pretty Good Privacy encryption 
infrastructure) or other web of trust. Authentication methods 
and tools are well-known in the art, at least with respect lo 
their use in authenticating individual users. 

A topology information scope definition such as the 
request scope 606 indicates the nature and scope of any 
topology information being requested or, in the case of an 
update, any topology information being provided. In the 
illustrated embodiment, the scope 606 includes a list or table 
608 identifying one or more source nodes, another list or 
table 610 identifying one or more destination nodes, weight- 
ing criteria 612, and an indication 614 of the relative priority 
of the request 600. 

For instance, a given request 600 might identify source 
node A, destination node B, weighting criteria "Secure 
Sockets I^yer available", and priority "low" for a weekly 
log archiving message 200 from an administrator on node A 
to an administrative archive process on node B. Another 
request 600 might identify the administrator's node as the 
source node, all departmental workstations as destination 
nodes, no specific weighting criteria, and a high priority for 
a message 200 warning that the system 100 is going off-line 
in five minutes for maintenance. Those of skill will identify 
many other instances of the request 600 which are suitable 
for particular situations, and/or suitable as defaults that may 
or may not be overridden by users, depending on the 
embodiment. 

Some requests 600 include a request 616 to forward one 
or more messages 200 along hidden paths 220 previously 
identified by the manager 212. Some requests 600 include a 
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request 616 to forward one or more messages 200 along any 
path, hidden or visible, which has a cost less than some 
specified threshold. Some requests 616 ask the manager 212 
to forward the messages 200 along any appropriate hidden 
path 220, but only if no visible paths to the destination 204 5 
can be shown to the requester. 

In alternative embodiments, one or more of the elements 
606 through 616 are omitted. For instance, the request scope 
606 may be implicitly defined as "everything you have" if no 
source or destination nodes are identified in the request 600. lo 
Likewise, some embodiments may assign weights using 
only one approach, so there is no reason to indicate which 
weighting criteria are of interest to the requester. Some 
embodiments may operate strictly on a firsl-come-first- 
served basis, so the priority of a given request 600 relative 15 
to other requests depends only on when the request is 
received. Some requests 600 seek only topology information 
214 and hence omit the forwarding request 616, while other 
requests 600 omit the scope definition 606 but contain a 
forwarding request 616. 20 

More generally, signal components, method steps, and 
system components shown in the Figures or discussed in the 
specification text may be omitted from some claimed 
embodiments, regardless of whether they are expressly 
described as optional in the specification. Conversely, claims 25 
may clarify or add steps or components, or repeal them. 
Steps and components may also be named differently. In 
addition, those of skill in the art will recognize when 
descriptions provided in connection with one step or com- 
ponent also pertain to another step or component, thereby 30 
making explicit repetition of the description unnecessary. To 
give but one example, the various ways of making a request 
during step 502 and the components of the request 600 are 
clearly related. 

Responses to Topology Information Requests 35 

FIG. 7 illustrates signal formats for responses from 
manager(s) 212 to users who sent requests 600. A manager 
response 700 includes a status field 702 containing a status 
value, status flag, or other indication of the general nature of 
the manager's response. If the authentication succeeded and 40 
the requested operation (such as "get topology information", 
"forward message", or "update your tables with this 
information") succeeded, then the status 702 will so indi- 
cate. However, in some embodiments the status is implicit in 
other components of the response 700. For instance, if 45 
topology information 214 was requested and is supplied in 
the response 700, then the status may be implicitly under- 
stood to be "OK." If the requested operation partially or 
entirely failed, then the status 702 may provide some indi- 
cation of the reason for failure, such as "authentication 50 
failed", "manager down for maintenance; try manager at 
address X", or "generating/updating topology information; 
please try again later". 

If the request 600 sought topology information and the 
information 214 is available and the requester is authorized 55 
to access it, then the response 700 includes the information 
214. The topology information 214 may include visible 
paths 218 in the form of one or more nodes, links, and/or 
weights which are represented as tables, lists, trees, graphs, 
or other data structures known in the art. 60 

Instead of visible paths 218, or in addition to such paths 
218, the topology information 214 may include hidden paths 
220. Each hidden path 220 includes at least two end nodes 
704. In the illustrated embodiment, each hidden path 220 
also includes one or more total weights 706 so the path 65 
selector 206 can select paths on the basis of the hidden path 
220 as a whole even though the path selector 206 lacks 
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detailed information about some individual nodes, links, 
and/or weights inside the hidden path 220. 

Note that paths in the response 700 may be hidden even 
when the corresponding request 600 is authenticated. The 
system 100 may be configured so that unauthorized users 
have no information about hidden paths 220 (not even the 
fact they exist), while some of the authorized users receive 
only summary information such as the end nodes 704 and 
total weight 706. 

The illustrated response 700 also includes a list or table 
708 of other manager 212 addresses. Such a list 708 may be 
provided in response to an explicit request by the path 
selector 206 directory interface 304. Alternatively, the list 
708 could be provided when the manager 212 in question 
does not have all the topology information 214 sought in the 
request 600. For instance, the given manager 212 might have 
no information regarding some or all of the destination 
nodes 610 specified in the request 600 but might also have 
the address of another manager 212 that is closer to those 
nodes 610. 

Conclusion 

The present invention provides improved tools for man- 
aging and using topology information in a distributed com- 
puting system. Distributed topology information managers 
provide efiScient yet controlled access to confidential topol- 
ogy data. Familiar authentication techniques can be used 
with the invention, and existing user rights databases may 
also be used. The invention can use either conventional or 
proprietary path selection criteria. 

The invention may be embodied in other specific forms 
without departing from its essential characteristics. The 
described embodiments are to be considered in all respects 
only as illustrative and not restrictive. As used here, the term 
"includes" means "includes, without limitation" or 
"comprises," rather than meaning "consists of." Any expla- 
nations provided herein of the scientific and organizational 
principles employed in the present invention are illustrative 
only. The scope of the invention is, therefore, indicated by 
the appended claims rather than by the foregoing descrip- 
tion. All changes which come within the meaning and range 
of equivalency of the claims are to be embraced within their 
scope. 

What is claimed and desired to be secured by patent is: 

1. A topology information manager in a distributed com- 
puter system, the topology information manager comprising; 

an authentication component for authenticating requests 
regarding information about the topology of at least a 
portion of the distributed computer system; 

a response component for providing responses to such 
requests; and 

a storage component for storing topology information, the 
storage component being configured by topology infor- 
mation in the form of a hidden path which includes an 
identification of at least two end nodes of a hidden path 
and which omits topology information about at least 
one path between the two end nodes. 

2. The topology information manager of claim 1, wherein 
the storage component comprises a volatile memory cache. 

3. The topology information manager of claim 1, further 
comprising topology information in the form of a partial tree 
representing at least two nodes and at least one link in the 
distributed computer system. 

4. A computer storage medium having a configuration that 
represents data and instructions which will cause perfor- 
mance of method steps for managing network topology 
information in a computer network, the method comprising 
the steps of: 
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receiving a topology information management request; 
authenticating the request; and 

managing hidden path topology information in response 
to the authenticated request. 

5. The topology information manager of claim 1, fiirther ^ 
comprising a forwarding component for receiving a data 
packet and forwarding it over a hidden path without fully 
disclosing the topology of the hidden path. 

6. The topology information manager of claim 1 in 
combination in the distributed computer system with a path 
selector, the path selector comprising: 

a request component for making an authenticated request 
to the topology information manager and receiving a 
response; and 

a path selection Component for selecting at least one path 
based at least in part on topology information provided 
in response to the authenticated request. 

7. The topology information manager of claim 1, wherein 
the topology information manager is located on a single 20 
node of the distributed computer system. 

8. The topology information manager of claim 7 in 
combination with at least one other topology information 
manager which is located on at least one other node of the 
distributed computer system. 25 

9. A path selector in a distributed computer system, the 
path selector comprising: 

a request component for making an authenticated request 
for topology information and receiving a response; and 

a path selection component for selecting at least one path 
based at least in part on topology information provided 
in response to the authenticated request, the path selec- 
tion component configured to select a path using topol- 
ogy information in the form of a hidden path which 
includes an identification of at least two end nodes of 
a hidden path and which omits topology information 
about at least one path between the two end nodes. 

10. The path selector of claim 9 in combination with a 
directory identifying at least one source of topology infor- 
mation. 

11. The path selector and directory combination of claim 
10, wherein the directory includes distributed replicated 
partitions. 

12. The path selector and directory combination of claim 
11 in further combination with a topology information 
manager identified in the directory, the topology information 
manager comprising: 

an authentication component for authenticating requests 

for access to topology information; 
a response component for providing responses to such 

requests; and 

a storage component for storing topology information. 

13. The path selector of claim 9, wherein the path selector 

is located on a single node of the distributed computer 55 
system. 

14. The path selector of claim 13 in combination with at 
least one other path selector which is located on at least one 
other node of the distributed computer system. 

15. A set of data signals embodied in a network connec- gg 
tion for topology fragment management, the data signals 
comprising: 

at least one topology information management request 

made by a requester; 
at least one authentication signal containing identification 65 

and credential data of the requester; and 
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at least one topology information hidden path signal 
which includes an identification of at least two end 
nodes of a hidden path and which omits topology 
information about at least one path between the two end 
nodes. 

16. The data signals of claim 15, further comprising at 
least one response to a topology information request in the 
form of a partial tree representing a portion of network 
topology. 

17. The data signals of claim 15, further comprising at 
least one data packet and a corresponding request that the 
data packet be forwarded over a hidden path. 

18. The data signals of claim 15, wherein the management 
request is a topology information update request from a first 
topology information manager to a second topology infor- 
mation manager. 

19. A method for managing network topology information 
in a computer network, comprising the steps of: 

receiving a request for topology information about the 

network; 
authenticating the request; 

providing topology information in response to the authen- 
ticated request; and 

selecting at least one path based at least in part on at least 
one hidden path provided by the providing step. 

20. The method of claim 19, further comprising at least 
two informing steps, each of which furnishes a different 
node in the network with topology information to be pro- 
vided in response to an authenticated request. 

21. The method of claim 19, further comprising the step 
of selecting at least one path based at least in part on at least 
one partial tree provided by the providing step. 

22. The configured storage medium of claim 4, wherein 
the managing step updates topology information in a topol- 
ogy information manager in response to the authenticated 
request. 

23. The method of claim 19, wherein the selecting step 
selects a path including at least two hidden paths. 

24. The method of claim 19, wherein the request is from 
a requester on a requesting node to a provider on a providing 
node, and the requesting node is different from the providing 
node. 

25. The method of claim 19, wherein the request is from 
a requester to a provider, and the requester and provider are 
on the same node. 

26. The method of claim 19, wherein the request is from 
a requester to a provider, and the method further comprises 
the steps of sending data from the requester to the provider 
and then forwarding the data over a hidden path from the 
provider without first fully disclosing the topology of the 
hidden path to the requester. 

27. The configured storage medium of claim 4, wherein 
the managing step provides topology information to a path 
selector in response to the authenticated request. 

28. The configured storage medium of claim 27, further 
comprising the step of selecting at least one path based at 
least in part on topology information provided during the 
providing step. 

29. The configured storage medium of claim 4, wherein 
the request is from a requester to a provider, and the method 
further comprises the steps of sending data from the 
requester to the provider and then forwarding the data over 
a hidden path from the provider without first fully disclosing 
the topology of the hidden path to the requester 

« ♦ « « ♦ 
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